The number of businesses exchanging information electronically is proliferating. Businesses that exchange information have recognized the need for a common standard for representing data. Extensible Markup Language (“XML”) is rapidly becoming the common standard for representing data.
XML describes and provides structure to a body of data, such as a file or data packet, referred to herein as an XML entity. The XML standard provides for tags that delimit sections of an XML entity referred to as XML elements.
An element may contain various types of data, including attributes and other elements. An element that is contained by another element is referred to as a descendant of that element. By defining an element that contains attributes and descendant elements, the XML entity defines a hierarchical relationship between the element, its descendant elements, and its attributes. A set of elements that have such a hierarchical relationship is referred to herein as an XML tree.
Industry standards define structures for representing XML trees. One such standard is the Document Object Model (DOM), promulgated by the World Wide Web Consortium (W3C). An XML tree that conforms to the DOM standard is herein referred to as a DOM tree.
In order for a computer to operate on an XML tree, an in-memory representation of the XML tree is generated. In general, an XML tree is read from a storage device (e.g., a disk that stores files that contain XML entities) to create in-memory data structures used to represent an XML tree. The in-memory data structures are manipulated by applications running on the computer. Typically, the applications access and manipulate the data structures through a set of routines or functions designed for this purpose.
The term DOM implementation is used herein to refer to a definition of data structures used to represent a DOM tree, functions or routines that are designed and used to interact with the data structures, or a combination thereof. A DOM implementation may define only data structures. A DOM implementation may be a set of object classes that define attributes and methods.
The term “application” is used to refer to a set of interrelated software modules that, when executed, provide a particular service or functionality. The term is used to refer to a source code version of the software modules, an executable or runtime version of the software modules, which may be contained in one or more executable programs or files, or versions of the modules stored in a library as object code.
Typically, a DOM tree is represented as a node tree, which is a set of linked nodes that are hierarchically related. A node in the node tree represents, for example, an element or an attribute. Links between a node and another node represent a hierarchal tree relationship between the nodes and their corresponding elements. For example, a node corresponding to a parent element may be linked to nodes representing child elements of the parent element.
W3C specifications define a common DOM implementation. These include the Document Object Model (DOM) Level 2 Core Specification (W3C recommendation 13 Nov. 2000) (herein Level 2 Core Specification), and the Document Object Model (DOM) Level 1 Specification (W3C recommendation 1 Oct. 1998), herein Level 1 Specification, the contents of which are incorporated herein by reference.
The W3C specifications are for object oriented languages, such as Java and C++. However, there is no industry standard that has been developed for languages that are non-object oriented. Thus, developers of XML applications and utilities implemented using non-object oriented languages design and use a potpouri of DOM implementations, most, if not all of them, comporting to no particular standard or common design. Consequently, non-object oriented applications developed by one set of developers likely cannot use a DOM implentation implemented by another set of developers without reprogramming the applications. This may be true even for applications developed by sets of developers within the same business enterprise.
For example, an Extensible Style Language Transformation (“XSLT”) processor is a software utility that interprets instructions written in the Extensible Style Language to transform an XML entity into another body of data conforming to another standard, such as another mark-up language (e.g. HTML), XML, or some other language. The reusability of a particular XSLT processor is enhanced if it can be used to translate data that is stored in structures that conform to different DOM implementations.
However, if an XSLT processor has to be reprogrammed to use each different DOM implementation, its reusability may be severely hampered. The time and effort for reprogramming an XSLT processor can be overwhelming, often making use of an XSLT processor for a particular application that uses a different DOM implementation very expensive and economically infeasible.
Based on the foregoing, it is desirable to provide a mechanism that allows a particular application written in a non-object oriented language to interact with different DOM implementations.